One of the most important aspects involved in the management of systems, network, and services is the need to create a model of the resources being managed, that is thorough enough to perform fault isolation, alert correlation, root-cause and service impact analysis, and yet will provide intuitive and easy to understand representations of the resources to end-users—the operators and technicians responsible for system monitoring and maintenance. Many standards development organizations (e.g., ITU, TINA, TMF, etc.) have created different models, separately describing different areas of problem domain. However, if one is faced with the task of managing networks that span several distinct and separately standardized problem domains, it becomes very difficult to build a shared knowledge base, or model, and apply a common set of rules and procedures in order to perform fault isolation, alert correlation, root-cause and service impact analysis.
FIG. 1 shows a conventional ‘classic’ approach to network and services modeling, comprised of a service management model at a service layer 100, which is coupled with a transport resources management model at a network layer 200, and communication information models (SONET, ATM, and SDH) at a network element layer 300. Using this paradigm becomes even more difficult, when taking into account the fact that some of the communication equipment performs functions in several domains (e.g., an ATM multiplexer with DSH/SONET line interfaces).
In an effort to remedy shortcomings of the classical approach of FIG. 1, it has been proposed to build a ‘Common’ or universal model that will describe all resources in a uniform or ‘normalized’ fashion. One relatively well know example of this is the Common Information Model (CIM) developed by DMTF (www.dmtf.org). The CIM approach allows fault isolation, alert correlation, root-cause and service impact analysis tasks to be performed across multiple domains of equipment, network and service management efficiently. However, it suffers the problem of being a domain oriented representation of the managed resources to the user. This means that something as familiar as classical SDH equipment will be now be represented in a completely different manner to operators and technicians who have studied, used and become familiar with that equipment for years.
To illustrate this difficulty, consider the CIM representation in FIG. 2 of a microwave radio 20. As shown therein, user-familiar attributes of the radio (exclusive of CIM modeling) may include its name 21 (e.g., ‘my radio’), an IP address 22 (137.237.1.1), a scan address 23 (99), and a network IP address 24 (192.168.1.2). This is how the radio presents itself to the user in a familiar manner (namely, how the user perceives the radio). Through CIM modeling, however, a first ‘functional attribute’ of the radio becomes a CIM computer system 31, which has the name attribute ‘my radio’. There is usually an associated set of additional (ten to twenty) attributes in the CIM model shown at 32, but something in which the user customarily has no particular interest. Branching from the principal functional element—the CIM computer system—are a plurality of ‘hosted access points’, a first of which is a CIM IP Protocol End Point 33, which corresponds to the IP address 22 of the radio (i.e., 137.237.1.1) and perhaps another five or six additional attributes, again something the user does not care about. Branching from a second ‘hosted access point’ is a CIM IP address 34, which corresponds to the network IP address 24 of the radio (i.e., 192.168.1.2); and branching from a third hosted access point is a third instance 35 of a scan protocol end point—the scan address 23 (99) of the radio.
It can be seen that CIM models resources in a very detailed and highly normalized fashion. It focuses on enterprise management, where everything is modeled down to a very fine detail. The structure of CIM—how the model breaks down the classes of managed elements and sets up relationships between them—allows most of the root cause/service and resource impact analysis tasks to be performed using a set of fixed, predefined business rules.
However, with all of the advantages and power of the CIM approach, there are certain drawbacks. One of them is the fact that it is harder to build applications that are focused on a particular area, like fault and configuration management, inventory, etc. CIM is too replete with functional definitions for each of the individual business domains. For example, it provides the operator with the primary focus in fault management a lot of pure inventory related information, which the operator doesn't really care about.